﻿Cryptext x64 0.11y dev28 fix3
==============================

Cryptext x64 is a modern native 64-bit file encryption program for Windows and a reimplementation of the classic Cryptext 3.4 Windows shell extension.

This version is still a development/test build. The modern CT64FILE-V1 file format is explicitly defined and was not changed by the 0.11x/0.11y feature work.

OVERVIEW
========

Cryptext x64 is written with FASM (Flat Assembler) as a native Win64/Win32 application. It does not require .NET, WebView, or a large additional runtime.

Files and folders can be processed in several ways:

- directly through the Cryptext user interface
- by drag & drop onto the main window
- through the Windows Explorer context menu
- by double-clicking .$#! files
- from the command line
- as multi-selection or mixed file batches
- recursively as folder selections

New encrypted files retain the familiar extension:

  .$#!

Cryptext x64 can also decrypt old .$#! files created by Cryptext 3.x/3.4. The old Cryptext 3.x/3.4 format is read only; new files are never created using the historical SHA-1/RC4 format.


MODERN FILE ENCRYPTION
======================

Newly encrypted files use the explicitly defined CT64FILE-V1 file format.

It uses:

- AES-256-GCM authenticated encryption
- PBKDF2-HMAC-SHA-256 for password-based key derivation
- a default writer policy of 600,000 PBKDF2 iterations for new CT64FILE-V1 files
- a fresh 16-byte salt per file
- cryptographically secure random values through Windows CNG / BCryptGenRandom
- 4 MiB data chunks when writing new files
- an individual 128-bit GCM authentication tag for every encrypted record
- authenticated metadata and header information

For CT64FILE V1, the password is processed as exact UTF-16LE code units. No terminating NUL is appended and no Unicode normalization is performed.

Large files are processed in chunks, so the complete file does not have to be loaded into memory.


GROUND PASSWORD FOR NEW ENCRYPTION
==================================

Cryptext x64 again follows the usability principle of classic Cryptext 3.4 for new encryption: a fixed Cryptext ground password helps prevent accidental encryption with a mistyped new password.

If no ground password has been configured yet:

- Cryptext offers a protected two-field setup dialog at program startup.
- The new password must be entered identically twice.
- Cancelling setup still allows Cryptext to be used for decryption.
- A later encryption request asks for setup again.

For later encryption:

- The entered password is checked against the local ground-password verifier before processing begins.
- Encryption starts only if it matches.
- A wrong password creates no temporary file and changes no user file.

Decryption continues to accept arbitrary passwords. This is necessary because a file may have been created with an older ground password, on another computer, by another Cryptext installation, or by Cryptext 3.x/3.4.

"Change password..." uses a dedicated three-field dialog:

  Current password
  New password
  Repeat new password

The change applies to future encryption. Existing .$#! files are not re-keyed and continue to require the password with which they were originally encrypted.

The local ground-password verifier does not store the ground password as plaintext. It uses random salt/verifier material and Current-User protection mechanisms. The verifier is a local usability/security check and does not change CT64FILE V1.


TRANSACTION-SAFE FILE PROCESSING
================================

Cryptext x64 is designed to commit a completed output file only after the complete operation has succeeded.

During encryption, a hidden temporary file is first created next to the source file. The processing sequence then includes:

- writing the complete encrypted output
- FlushFileBuffers / disk synchronization
- reopening or rereading the written data
- deriving the key again
- authenticating all GCM records
- comparing the recovered bytes with the still untouched source
- only then performing the final rename/commit
- restoring supported timestamps and attributes
- optionally deleting the source only after a successful commit

During modern decryption, metadata is authenticated before a plaintext work file is created. After the plaintext has been written, a second complete GCM verification pass is performed. A wrong password, corrupted file, or invalid GCM tag must not be committed as a successfully decrypted output file.

Cryptext does not silently overwrite an existing destination file.


FOLDERS, BATCHES, AND DRAG & DROP
=================================

Folders are not encrypted as container files. Cryptext recursively walks the directory tree and processes every contained file as its own safe transaction.

Important rules:

- Subdirectories are processed recursively.
- Reparse points, junctions, and symbolic links are deliberately not followed.
- The directory structure itself remains in place.
- Failure of one file does not roll back files that were already processed successfully.
- Large recursive file lists are managed dynamically; folders containing several thousand files are no longer limited by the earlier static list buffer.

Explorer folder context menu:

- Encrypt: process ordinary files and skip existing .$#! files.
- Decrypt: process only .$#! files.

If a drag-and-drop selection contains at least one folder, Cryptext first shows a mode chooser:

  Encrypt
  Decrypt
  Automatic
  Cancel

This only selects the processing mode. Actual processing still begins only after OK in the main window.


LEGACY CRYPTEXT 3.x/3.4 FILES
=============================

Cryptext x64 0.11v and later include a separate decrypt-only compatibility path for original Cryptext 3.x/3.4 files.

The old format uses the historical Cryptext construction based on SHA-1 and RC4. This compatibility path exists solely for backward compatibility and recovery of old files.

Important:

- New encryption always uses CT64FILE V1 and AES-256-GCM.
- Cryptext x64 never creates new SHA-1/RC4 files.
- The historical Cryptext 3.x/3.4 format does not provide a modern full-file MAC/AEAD integrity check over the complete ciphertext body.
- Supporting old files does not retroactively make their historical cryptographic design modern.

Legacy compatibility was tested with genuine Cryptext 3.4 files of multiple sizes. Version 0.11v fix2 also reproduces the historical SHA-1 word byte representation used by the original application.


PASSWORD INPUT AND VIRTUAL KEYBOARD
===================================

Cryptext x64 uses its own protected SecureInput buffer. In the intended workflow, the visible Windows password field is used only to display bullet characters.

The virtual keyboard:

- does not use SendInput, keybd_event, or synthetic WM_KEYDOWN/WM_CHAR events
- can reshuffle its character positions on request using BCryptGenRandom
- uses QWERTZ in the German interface and QWERTY in the English interface
- supports Shift
- briefly hides sensitive key labels and the mouse pointer during sensitive clicks
- uses WDA_EXCLUDEFROMCAPTURE on a best-effort basis; failure does not block Cryptext
- is aligned with the visible left edge of the main window in NC-skin mode; dev28 fix3 contains the final 2-pixel adjustment and accounts for invisible window frames at the monitor edge


MAIN WINDOW, NC SKIN, AND EMERGENCY MODE
========================================

Since 0.11y dev27, Cryptext has used its own compact 20-pixel title bar. It contains the NC logo, the pin control, and the minimize and close buttons. The window can be dragged by the title bar; right-clicking opens the system menu. Double-clicking the NC logo changes the color theme.

A deliberately simple registry switch is available as an emergency fallback:

  Key:   HKCU\Software\Cryptext64
  Value: NoSkin (REG_DWORD)

Cryptext automatically creates the value as 0 if it is missing or invalid. A value of 0, or any value other than 1, enables the NC skin. A value of 1 starts Cryptext with the classic native Windows title bar and the original window geometry the next time the program is launched.

In 0.11y dev28 fix2, positioning of the virtual keyboard and the "Change password" dialog at monitor edges was changed to use the visible window edges. dev28 fix3 moves only the virtual keyboard another 2 pixels to the right compared with fix2; the password dialog and NoSkin behavior remain unchanged.


REMEMBER UNTIL WINDOWS SIGN-OUT / SYSTEM TRAY
=============================================

Cryptext provides two memory options:

  Do not keep in memory
  Remember until Windows sign-out

When the second option is used and a valid ground password is present in the session buffer, Cryptext can retain the password in memory for later operations during the same Windows session.

Rules:

- For this feature, the password is not persistently stored as plaintext in the registry, nor is a password hash that can directly decrypt files stored there.
- X/Alt+F4 hides Cryptext to the system tray in this state instead of terminating the running instance.
- Double-clicking the tray icon restores the existing main window.
- "Clear password from memory" immediately wipes the remembered password and also disables Explorer Quick Mode if it is active.
- "Do not keep in memory" also clears the session buffer immediately.
- On normal Windows sign-out/restart, the running Cryptext instance ends; the session password is no longer available afterward.
- After an Explorer restart, Cryptext automatically re-adds its tray icon.

The detailed security notice for this option appears as a tooltip when the pointer is over "Remember until Windows sign-out".

Security boundary: a password retained in RAM cannot be guaranteed to remain hidden from sufficiently privileged processes on an already compromised system. Memory contents may also reach the page file, hibernation data, or crash/memory dumps under some circumstances. Use this feature only on a Windows system and user account you trust.


SINGLE INSTANCE AND REQUEST HANDOFF
===================================

At most one normal Cryptext64.exe runs per interactive Windows session.

A later Cryptext process transfers only the following to the already running instance:

- operation mode
- keep/delete-source setting
- filesystem paths

Passwords, password hashes, vault secrets, and file keys are not transferred between processes.

While one request is already active or staged, exactly one genuinely different request may wait separately. In the current development build, identical duplicate Explorer requests are suppressed so the same file is not immediately processed a second time as a pending request.


LOCAL PASSWORD VAULT
====================

Cryptext x64 includes an optional local password vault for the long Cryptext password.

The vault uses, among other mechanisms:

- Current-User DPAPI
- PBKDF2-HMAC-SHA-256
- AES-256-GCM
- a random VaultKey
- two A/B registry slots with generations and complete cryptographic validation
- a 4- to 6-digit PIN
- a dedicated PIN dialog
- an optional randomized on-screen numeric keypad
- best-effort VirtualLock for the private vault workspace

After successful PIN authentication, the vault can load the password stored there back into the protected SecureInput buffer.

Important in the current 0.11y development build: "Change password..." changes the Cryptext ground password for future encryption. An already configured local vault is not updated automatically and may still contain the previously stored password. Existing .$#! files are likewise not changed by a ground-password change.


EXPLORER INTEGRATION
====================

Cryptext64Shell.dll is a small native x64 shell extension.

It receives selected file/folder paths from Explorer and starts or activates the existing Cryptext64.exe processing path.

The Explorer process does not contain:

- passwords
- PBKDF2 file keys
- AES-GCM file keys
- vault session secrets

Context menu:

- ordinary files: Encrypt
- .$#! files: Decrypt
- mixed selection: Cryptext / automatic processing
- folders: Encrypt or Decrypt

The .$#! extension intentionally remains visible.

Double-clicking a .$#! file starts or activates Cryptext in decrypt mode.

Without Explorer Quick Mode, the actual file operation still begins only after explicit OK confirmation in the Cryptext main window.

On Windows 11, the classic IContextMenu extension may appear under "Show more options".


EXPLORER QUICK MODE
===================

The tray menu can optionally enable "Explorer Quick Mode (no confirmation)".

Requirements and limits:

- A valid ground password must be remembered in the Cryptext process for the current Windows session.
- Cryptext must remain running in the tray.
- Quick Mode applies only to explicit Encrypt/Decrypt requests from the Cryptext Explorer extension.
- Drag & drop, AUTO requests, and ordinary command-line launches retain the visible confirmation flow.
- Quick Mode itself is not stored persistently and is off again after a Cryptext/Windows restart.
- Clearing the session password disables it immediately.

The very first activation shows a detailed security dialog. The Activate button is initially disabled and becomes available only after the user checks a box confirming that the warning was read and understood. Only the fact that the warning has already been acknowledged is stored persistently.

For decryption, the password currently stored in the session buffer is used. If it does not match the file, the file is not silently decrypted successfully; Cryptext becomes visible and returns to the normal password/error flow.

Important security note: Quick Mode deliberately removes the additional confirmation in the main window. Another program running under the same Windows user account could in principle try to trigger Cryptext requests. By enabling Quick Mode, the user explicitly accepts this additional convenience/security trade-off. The password itself is still not transferred to the triggering process.


LANGUAGE AND USER INTERFACE
===========================

Cryptext x64 can switch between German and English.

Additional functions include:

- drag & drop of files and folders
- mixed encryption/decryption batches
- "file x of y" progress display
- speed, file size, and approximate ETA for longer operations
- visible disk-sync phase
- cooperative cancellation up to the safe finalization boundary
- Always on Top through the native window system menu
- Explorer file icons
- native About dialog
- hidden four-state file-icon selector in the About dialog:
    classic key
    AES v2
    AES v3
    BeOS v4
- optional miniature RAM display toggled with Shift+Info:
    RAM: <PrivateUsage> / <WorkingSetSize> MiB
  The display is hidden by default, updates once per second while visible, and is not persisted.


INSTALLING FROM THIS SOURCE PACKAGE
===================================

Requirement:

The current build script expects FASM 1.73.35, or a compatible FASM installation, at:

  C:\fasm\FASM.EXE
  C:\fasm\INCLUDE

1. Extract the complete Cryptext x64 package to a normal folder.

2. Run:

  build.bat

A successful build creates:

  bin\Cryptext64.exe
  bin\Cryptext64Shell.dll

3. To install the Explorer integration, then run:

  install_shell_user.cmd

The current installer uses per-user HKCU registration and is designed not to require administrator rights.

Files are installed to:

  %LOCALAPPDATA%\Cryptext64

The installer registers:

- Cryptext64Shell.dll as an x64 Explorer context-menu extension
- the .$#! file type
- the Explorer file icon
- the double-click decrypt command
- Cryptext Explorer context-menu commands for files and folders

On a first installation, Explorer is not unnecessarily stopped or restarted.

During an update, the installer may briefly stop and restart Explorer so an older in-process Cryptext64Shell.dll can be unloaded and replaced.

Package paths containing parentheses are supported by the current installer.


USING CRYPTEXT WITHOUT EXPLORER INTEGRATION
===========================================

After a successful build, Cryptext64.exe can also be launched directly. The Explorer shell extension is only required for the Explorer context menu and file association.


COMMAND LINE
============

Examples:

  Cryptext64.exe --encrypt "D:\Test\a.bin" "E:\Other\b.mkv"

  Cryptext64.exe --decrypt "D:\Test\a.bin.$#!"

  Cryptext64.exe --auto "D:\Test\plain.txt" "E:\Other\secret.$#!"

Optional source-retention overrides:

  --keep-original
  --delete-source

Ordinary command-line requests do not automatically start cryptography. Paths are staged or handed to the active Cryptext instance first. The visible password/confirmation flow remains in place.

With "--auto", the .$#! suffix determines per file whether Cryptext encrypts or uses the modern/legacy decrypt path.


UNINSTALLATION
==============

To remove the Explorer registration, run:

  uninstall_shell_user.cmd

Restart Explorer or sign out/in afterward so a loaded shell DLL is released.

The uninstall script intentionally does not automatically delete the installed program directory. After Explorer has restarted, the directory can be removed manually:

  %LOCALAPPDATA%\Cryptext64


NO "SECURE ERASE" PROMISE
=========================

Cryptext x64 does not promise secure physical sector overwriting.

Original and work files that are no longer required are removed through normal Windows file-system operations. An application cannot guarantee that every historical plaintext copy or physical data remnant has disappeared.

Additional copies or remnants may exist because of, among other things:

- SSD wear leveling
- file-system and storage caches
- Volume Shadow Copy / VSS
- backups
- cloud synchronization and version history
- snapshots
- copy-on-write systems
- other operating-system or storage mechanisms

Full-disk encryption is an additional useful protection layer for data at rest on a powered-off device.


SECURITY NOTE
=============

No encryption program can turn a weak password into a strong secret.

For important files, use a long, unique, difficult-to-guess password and keep it safely available. There is no intended recovery mechanism for a modern CT64FILE-V1 file if the correct password is lost.

Remember-until-sign-out and especially Explorer Quick Mode are deliberate convenience features with additional risks. Read the associated security notices in full before enabling them.


ROADMAP
=======

The following items are planned or are being evaluated for later development:

- differentiated batch cancellation: skip current file / abort entire request / continue processing
- free-space precheck before larger file operations
- a safe %TEMP% fallback when a work file cannot reasonably be created next to the source file
- later handling of NTFS Alternate Data Streams (ADS), including a clear user decision and an "apply to all" batch option
- a standalone Recovery Decryptor for long-term recoverability
- further hardening of temporary plaintext work files
- persistent PIN anti-hammering for the local vault
- a separate "Cryptext x64 Argon2id Extra Edition" using the memory-hard Argon2id KDF; existing PBKDF2 files are intended to remain readable

This roadmap is not a promise of a specific release date or an unchanged technical implementation.


LICENSE
=======

The source code is provided under the "Source Code Inspection License" supplied with the package.

Please read LICENSE.txt, or the supplied license file, in full before compiling, modifying, or otherwise using the source code.

The license specifically permits personal inspection, security review, study, and private compilation for testing and verification. Redistribution, publication, distribution of derived builds, or incorporation into other distributed projects is not permitted without prior written permission from the copyright holder.

Under the current license text, the German version prevails in the event of an unintended discrepancy between the German and English versions.


CURRENT STATUS
==============

Current README/development status:

  Cryptext x64 0.11y dev28 fix3

0.11y dev28 fix3 builds on the dev19 functional state and includes the memory, progress, and PE-layout optimizations from dev20 through dev26, the NC skin from dev27, and the automatically created NoSkin emergency switch plus corrected window positioning from dev28. The final 2-pixel virtual-keyboard adjustment, the recommended tests, and the visual test were confirmed on September 20, 2026. CT64FILE V1, modern file cryptography, and the confirmed legacy Cryptext 3.x/3.4 decrypt-only algorithm remain unchanged.

For the consolidated development history, see:

  CHANGELOG-EN.txt
